- started 2018-09-16 by pulling TheProject starting point from GitHub.
- made basic UML diagram of what is given
- began planning out the project in the UML diagram
	- keep it simple: only squash for now
	- required a bit of work to get into the "builder" pattern. difficult to understand
	- also, a very complicated diagram. Made sure to use the correct arrows using UMLet.
	- more specific variables and methods are added during coding. Enjoy the dynamic of actually doing things
	- added a game class as an interactive component, as well as a few models with views and controllers
	- game window is where the game actually takes place. May be useful to separate between actual window, because ball depot could be e.g. at the right side 
- continued on to define some things in the TheApp class
	- set size to 16:9 relation
	- changed mouseClicked to keyPressed, since I prefer keyboard controls
	- turns out to be very simple to finish, since all of the logic is in other classes
- next: interactive component builder
	- create game class with its planned methods first
	- game will also need access to PApplet to process input. Makes no sense to do that at TheApp class
	- actually, next steps are very simple. Just call given build methods of game class
	- String type parameter in builder confused me. I decided to settle for a constant instead that allows choosing the type. hex-Number is more or less random
	- PROBLEM: variables declared in a switch case statement, or even in an if are obviously local. 
		- thus, it can't be returned later on after exiting the switch-case statement.
		- required to declare variable outside, but at that point the type is unknown
		- therefore, use abstract class InteractiveComponent. But this lacks the methods, which leads to failure when putting a game into the variable
		- SOLUTION: edit abstract class to force every descendant to have these methods
- continue by implementing game class
	- many other classes from the model, view and controller have to be defined now. So that's what I do
	- decided that floats in models are unnecessary. ints are precise enough for this coordinate system
	- had to change a few variables along the way. as obvious, planning is not my thing. For instance, decided to add stepWidth variable for Paddle controllers
	- finally able to implement build methods.
	- decided to put constants at beginning to ease changing things and increase readability
	- unfortunately, integers may cause imprecision of one pixel at a time. maybe change back to floats later on.
- next up, want to see something!!! began with game window
	- Found that name isn't very fitting so, changed it to game field instead
	- also changed way coordinates and widths are taken. After all, bottom "death" part is still part of field. Use distance top and width instead
	- no output at that point. Figure I have to implement other methods first, so I did
	- did ball and paddle. seemed very easy.
	- fixed an error in which I forgot to pass display into Game constructor. Game needs the display for drawing, building and calculating.

- proceeded by adding input logic to Game class. Depending on which button pressed, call controllers
- now implement controllers
	- paddle controller strategy left, constructor to build actual controllers required
	- now, there was a problem. Needed to determine which controller to choose: controller move, or controller boundary.
	- controller strategies don't know the GameField, though.
	- decided to give paddle an additional attribute: boundaryLeft and boundaryRight. The x coordinates which it may not move past.
	- I found that constantly updating the UML diagram was getting too annoying and was not worth it. Therefore, didn't work on it anymore
	- implementing controllers was again very easy due to the modularity. 
	- Though I had to decide on controller boundary snapping the paddle to either side, depending on its current position
	- paddle now able to move within bounds of game window, as schematic shows. Half a paddle at a time.
- time to implement ball logic
	- noticed I need much more information in the ball controller than originally thought
	- not just ball, but also paddle and gamefield. In fact, every object the ball might collide with
	- also, had to add "ballDeathLine" to gameField, so ballcontroller knows when ball is supposed to die
	- also added convenience functions in GameField to determine boundary
	- proceeded to write logic. 
	- Also added bounceX and bounceY to Ball model. Important: I made sure that ball doesn't boucne immediately, since that'd be a problem with velocity greater than 1.
	- realize that implementation may cause trouble when bouncing in corner; and it doesn't bounce off side of paddle, only top. But let's see.
	- in order to make ball update every time a screen is drawn, had to hook it into InteractiveComponent.update()
	- so I don't have to re-type what was already inside there because i had to override in Game, I decided to rename given update method to updateViews
	- that's then called in the actual update() method. can easily override and extend now
- unfortunately, ball moved only few times, then ran into an error
	- turned out to be a simple mistake on my side. Used getX when it should have been getY.
	- but paddle collision causes an exception, which I've implemented into bounceY and bounceX (fortunately)
	- again, an arithmetic mistake made by me
	- same for the bouncing off walls (negative velocities weren't considered)
	- but finally, it worked very well
- now I decided to make the ball faster every ten seconds
	- made ballcontroller know how high the frame rate is to calculate number of frames to pass before increasing speed (i.e. framerate (second) * amount of seconds)
	- added counter; whenever the critical number of frames has been passed, increase by one
	- works well, but the ball increases too instantly. The user can clearly see it the first time.
	- thus, increase gradually. Every frame a little bit!
	- changed all or at least most of the integers to floats
	- then went for a gradual increase by SPEED_INCREASE/CRITICAL_FRAME_NUMBER
	- realized I need to divide float by number, or else I won't get a proper floating point result

- next, I just wanted to implement a timer so the player knows how long they've made it.
	- again, model view controller pattern as per usual
	- went for precision up to a tenth
- now, the game over scenario. I'll keep the goal simple for now, since I want to change it with a balldepot later on.
	- so, the ball should die once it passed the death zone. I'll add a check in the update method of the game for that.
	- fairly difficult to proceed from here. I do plan there to be a ball depot with three balls. So I decide to implement that first
	- I decided not to implement a controller, since it seemed unnecessary
	- view was of course implemented
	- ball depot is a bit dynamic in the way that it scales ball's size if there are more or less of them sot hat they all fit into it
	- still not flawless of course, since great numbers of balls make them tiny as they are not displayed in multiple rows yet
- ball depot has to come to use of course, so now we need to make balls out of bounds die and enable user to put balls into the field
	- start with the latter. first of all, there is no ball. user has to press space bar in order to insert it.
	- as already implemented, one ball is removed from the top of the depot and inserted into the game
	- unfortunately, in order to deal with views array, had to create a dummy. That doesn't seem very clean to me. But it works.

- now, I also want to make sure the timer is saved for later, because I want to display the best time on the game over screen
	- extend Timer class a bit with static method to compare timers as well as method to export timer state as an int array
	- save all that into an array list in Game class for later reference
- finally, the game over screen
	- add boolean function to BallDepot model. public boolean depleted(). Returns yes if no balls are left.
	- add new model GameOverScreen along with a view for it.
	- once all balls are depleted, update method will replace Ball View with a game over screen view that's drawn above everything else. The game is left soft-locked.
- there's room for a few extras. For instance, a welcome message. Again, another view is created (though there isn't actually a model for this one)
	- just a simple message drawn in the middle of the screen.
	- strangely, other texts are moved a little bit to the left when using it. It's because I specified text alignment. Had to do it explicitly everywhere to avoid this problem
- as the final polish, I renamed the game from "TheApp" to "SquashIT". Basically, refactoring the TheApp class with rename did all it took for this.
	